Listen to This Blog
 

To put it bluntly, your latest and greatest product feature or code fix may only be applicable for a minority of your customers. If your company’s international revenue is approaching or has already surpassed 50% – but customers outside of the home market cannot use all product functions – there’s a problem. The product that you work so hard to perfect can’t be considered world-class until the world beyond your primary market can gain 100% access to features that make sense for their user environment.
So how do you make sure that your colleagues who are responsible for localization can keep up as your team iterates faster and faster? By meeting internationalization compliance standards that ensure that your team delivers world-ready code on time every time. Continuous localization is no longer continuous if the localization team must frequently stop workflows to fix stuff, or worse yet, wait on you to fix it. That’s where internationalization compliance for your code comes into play.
Based on 53 in-depth interviews with organizations that have implemented a continuous localization model, here are seven actions that you and your teams can take to better support your localization colleagues.
 

• Accept that internationalization compliance is similar to security. And accessibility. It’s an essential platform requirement, not a nice-to-have. You can’t even sell well in Australia or the U.K. unless your software supports appropriate currencies, date/time formats, and so on, even when products remain in (American) English. At a minimum, this means following the platform guidelines for internationalization compliance, rather than expending (unnecessary) creativity to reinvent the wheel – however useful the shortcuts may appear. 
   
• Prepare to be held accountable. Unfortunately, no software development framework has ever been designed with world-readiness as one of its pillars – despite software content rarely being used only by people whose native language matches that of the original UI. The gaps in these models continue to lead teams like yours to contest prioritizing proper internationalization enablement throughout a product’s lifetime as all teams vie for funding and resources. Don’t be a roadblock for local markets – work together with international colleagues to define exactly what 100% responsibility for internationalization compliance means. Support localization teams to ensure that product managers, testers, and content designers also buy in to the definition.
   
• Get trained – and stay trained – in internationalization compliance. Localization teams, along with their language and testing partners, are almost always thrilled to help software teams hone their internationalization skills. The developers and localizers interviewed for our research shared several delivery mechanisms for ongoing training as well as introductory sessions for new hires. One of the most popular methods is localization bug hackathons.
   
• Implement scorecards. One of the most effective ways for developers to commit, sustain, and track internationalization compliance – for new or legacy products – is internationalization compliance scorecards or report cards. Collaborating with localization teams, you can schedule specific commitments, track progress, and phase in what needs to be done. Use the scorecards to make the case for resources at the executive level to accomplish what is required within realistic timeframes. Track internationalization bugs by month or by quarter. If a team starts to generate an inordinate amount of bugs, make sure that the right people receive appropriate guidance or training to bring them back up to par. Have fun with the scorecards by generating friendly competition between teams.

• Investigate creating hooks into your code to support testing and context. Simply following internationalization compliance may not always be enough to maintain continuous localization at a high velocity. Collaborate with localizers to see if you can develop hooks in your code to allow for automated testing scenarios. That way, software testers and localizers no longer have to fumble around trying to figure out ways to recreate as many scenarios as possible.
   
• Demonstrate to “developer divas” how to excel at compliance. Developers whom we interviewed had advice for collaborating with colleagues whose attitude is, “You’re adding to my workload with your continuous localization model.” Enable localization teams to approach these colleagues from the point of view of, “Want your product to be successful beyond the domestic market? Here’s how to do it, and we’ll help you get there quickly.” Demonstrate how internationalization-vetted code libraries will help reduce their workload. Confirm the localization tasks that belong in the “busywork” category, and then collaborate to eliminate as many as possible through automation. Encourage a localization team member to attend Agile stand-ups, retrospectives, or meta-Scrums for new software features. 
   
• Explore why the “Spotify Model” strikes fear in the hearts of localizers. While controlled chaos may be great for you as a creative engineer because it removes processes that get in your way, that’s not necessarily the view from your localization team. The Spotify Model has a big impact on localization because development teams constantly morph – even more than usual. That makes it difficult to trace code back to the people who develop it. Avoid this nightmare by delivering internationalization-compliant code, regardless of new teammates joining and old ones leaving.

The good news is that you shouldn’t have to think much about localization as long as: 1) Your code is clean and internationalization-compliant from the start; 2) you maintain infrastructure (including version control systems); and 3) you provide screenshots and comments for your code to localization teams. Remember to approach internationalization compliance on the same level as compliance for security and accessibility by providing ongoing training for the area and supporting localization teams to participate in product design and to resolve context as a blocker.